Härdning av frontend-säkerhet: Content Security Policy och CORS

I dagens sammanlänkade digitala landskap är frontend-säkerhet av största vikt. Webbapplikationer är alltmer måltavlor för sofistikerade attacker, vilket gör robusta säkerhetsåtgärder avgörande. Två viktiga komponenter i en säker frontend-arkitektur är Content Security Policy (CSP) och Cross-Origin Resource Sharing (CORS). Den här omfattande guiden ger en djupgående titt på dessa tekniker och erbjuder praktiska exempel och användbara insikter för att hjälpa dig att stärka dina webbapplikationer mot moderna hot.

Vad är Content Security Policy (CSP)?

Content Security Policy (CSP) är ett extra säkerhetslager som hjälper till att upptäcka och mildra vissa typer av attacker, inklusive Cross-Site Scripting (XSS) och datainjektionsattacker. CSP implementeras genom att webbservern skickar en Content-Security-Policy HTTP-responshuvud till webbläsaren. Denna rubrik definierar en vitlista över källor som webbläsaren får läsa in resurser från. Genom att begränsa källorna till innehåll som en webbläsare kan läsa in gör CSP det betydligt svårare för angripare att injicera skadlig kod på din webbplats.

Hur CSP fungerar

CSP fungerar genom att instruera webbläsaren att endast läsa in resurser (t.ex. skript, formatmallar, bilder, teckensnitt) från godkända källor. Dessa källor specificeras i CSP-huvudet med hjälp av direktiv. Om en webbläsare försöker läsa in en resurs från en källa som inte är uttryckligen tillåten, kommer den att blockera begäran och rapportera en överträdelse.

CSP-direktiv: En omfattande översikt

CSP-direktiv styr de typer av resurser som kan läsas in från specifika källor. Här är en genomgång av några av de viktigaste direktiven:

• default-src: Anger standardkälla för alla innehållstyper. Detta är ett reservdirektiv som gäller när andra, mer specifika direktiv inte finns.
• script-src: Anger de källor från vilka skript kan läsas in. Detta är avgörande för att förhindra XSS-attacker.
• style-src: Anger de källor från vilka formatmallar kan läsas in.
• img-src: Anger de källor från vilka bilder kan läsas in.
• font-src: Anger de källor från vilka teckensnitt kan läsas in.
• media-src: Anger de källor från vilka ljud och video kan läsas in.
• object-src: Anger de källor från vilka plugins (t.ex. Flash) kan läsas in. Detta ställs ofta in på 'none' för att inaktivera plugins helt på grund av deras inneboende säkerhetsrisker.
• frame-src: Anger de källor från vilka ramar (t.ex. <iframe>) kan läsas in.
• connect-src: Anger de webbadresser som användaragenten kan ansluta till med hjälp av skriptgränssnitt som XMLHttpRequest, WebSocket och EventSource.
• base-uri: Anger de webbadresser som kan användas i ett dokuments <base>-element.
• form-action: Anger de webbadresser till vilka formulärinlämningar kan skickas.
• upgrade-insecure-requests: Instruerar användaragenten att automatiskt uppgradera osäkra begäranden (HTTP) till säkra begäranden (HTTPS).
• report-uri: Anger en webbadress där webbläsaren ska skicka rapporter om CSP-överträdelser. Detta direktiv är föråldrat till förmån för `report-to`.
• report-to: Anger ett rapporteringsgruppnamn som definieras i `Report-To`-huvudet, där webbläsaren ska skicka rapporter om CSP-överträdelser.

CSP-källlistnyckelord

Inom CSP-direktiv kan du använda källlistnyckelord för att definiera tillåtna källor. Här är några vanliga nyckelord:

• 'self': Tillåter resurser från samma ursprung (schema och värd) som dokumentet.
• 'none': Förbjuder resurser från alla källor.
• 'unsafe-inline': Tillåter användning av inline-skript och stilar (t.ex. <script>-taggar och stilattribut). Använd med extrem försiktighet eftersom det avsevärt försvagar CSP-skyddet mot XSS.
• 'unsafe-eval': Tillåter användning av dynamiska kodutvärderingsfunktioner som eval() och Function(). Använd med extrem försiktighet eftersom det introducerar betydande säkerhetsrisker.
• 'unsafe-hashes': Tillåter specifika inline-händelsehanterare eller <style>-taggar som matchar en specificerad hash. Kräver webbläsarstöd. Använd med försiktighet.
• 'strict-dynamic': Specificerar att förtroendet som uttryckligen ges till ett skript som finns i markeringen, genom att åtfölja det med en nonce eller hash, ska spridas till alla skript som laddas av det rotskriptet.
• data: Tillåter data: URI:er (t.ex. inline-bilder kodade som base64). Använd med försiktighet.
• https:: Tillåter att resurser läses in över HTTPS från vilken domän som helst.
• [värdnamn]: Tillåter resurser från en specifik domän (t.ex. example.com). Du kan också ange ett portnummer (t.ex. example.com:8080).
• [schema]://[värdnamn]:[port]: En fullständigt kvalificerad URI, som tillåter resurser från det specificerade schemat, värden och porten.

Praktiska CSP-exempel

Låt oss titta på några praktiska exempel på CSP-huvuden:

Exempel 1: Grundläggande CSP med 'self'

Denna policy tillåter resurser endast från samma ursprung:

            Content-Security-Policy: default-src 'self'
            

              
                Copy
              
            
          

Exempel 2: Tillåta skript från en specifik domän

Denna policy tillåter skript från din egen domän och en betrodd CDN:

            Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com
            

              
                Copy
              
            
          

Exempel 3: Inaktivera inline-skript och stilar

Denna policy förbjuder inline-skript och stilar, vilket är ett starkt försvar mot XSS:

            Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'
            

              
                Copy
              
            
          

Viktigt: Att inaktivera inline-skript kräver att du refaktorerar din HTML för att flytta inline-skript till externa filer.

Exempel 4: Använda Nonces för Inline-skript

Om du måste använda inline-skript, använd nonces (kryptografiskt slumpmässiga engångstoken) för att vitlista specifika inline-skriptblock. Detta är säkrare än 'unsafe-inline'. Servern måste generera en unik nonce för varje begäran och inkludera den i både CSP-huvudet och <script>-taggen.

            Content-Security-Policy: default-src 'self'; script-src 'nonce-r4nd0mN0nc3'; style-src 'self'
            

              
                Copy
              
            
          

            <script nonce="r4nd0mN0nc3"> console.log('Inline script'); </script>
            

              
                Copy
              
            
          

Obs: Kom ihåg att generera en ny nonce för varje begäran. Återanvänd inte nonces!

Exempel 5: Använda Hashar för Inline-stilar

I likhet med nonces kan hashvärden användas för att vitlista specifika inline-<style>-block. Detta görs genom att generera en SHA256-, SHA384- eller SHA512-hash av stilinnehållet.

            Content-Security-Policy: default-src 'self'; style-src 'sha256-HASHEDSTYLES'
            

              
                Copy
              
            
          

            <style sha256="HASHEDSTYLES"> body { background-color: #f0f0f0; } </style>
            

              
                Copy
              
            
          

Obs: Hashar är mindre flexibla än nonces eftersom alla ändringar av stilinnehållet kommer att ogiltigförklara hashen.

Exempel 6: Rapportera CSP-överträdelser

För att övervaka CSP-överträdelser, använd direktivet report-uri eller report-to:

            Content-Security-Policy: default-src 'self'; report-to csp-endpoint;
            

              
                Copy
              
            
          

Du måste också konfigurera Report-To-huvudet. Huvudet Report-To definierar en eller flera rapporteringsgrupper, som anger var och hur rapporter ska skickas.

            Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"https://example.com/csp-report"}]}
            

              
                Copy
              
            
          

Testa och distribuera CSP

Implementering av CSP kräver noggrann planering och testning. Börja med en restriktiv policy och lossa den gradvis efter behov. Använd huvudet Content-Security-Policy-Report-Only för att testa din policy utan att blockera resurser. Detta huvud rapporterar överträdelser utan att tillämpa policyn, vilket gör att du kan identifiera och åtgärda problem innan du distribuerar policyn i produktion.

            Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-endpoint;
            

              
                Copy
              
            
          

Analysera rapporterna som genereras av webbläsaren för att identifiera eventuella överträdelser och justera din policy därefter. När du är säker på att din policy fungerar korrekt distribuerar du den med huvudet Content-Security-Policy.

Bästa metoder för CSP

• Börja med en default-src: Definiera alltid en default-src för att fastställa en grundläggande policy.
• Var specifik: Använd specifika direktiv och källlistnyckelord för att begränsa omfattningen av din policy.
• Undvik 'unsafe-inline' och 'unsafe-eval': Dessa nyckelord försvagar CSP avsevärt och bör undvikas när det är möjligt.
• Använd nonces eller hashvärden för inline-skript och stilar: Om du måste använda inline-skript eller stilar, använd nonces eller hashvärden för att vitlista specifika kodblock.
• Övervaka CSP-överträdelser: Använd direktivet report-uri eller report-to för att övervaka CSP-överträdelser och justera din policy därefter.
• Testa noggrant: Använd huvudet Content-Security-Policy-Report-Only för att testa din policy innan du distribuerar den i produktion.
• Iterera och förfina: CSP är inte en engångskonfiguration. Övervaka och förfina kontinuerligt din policy för att anpassa dig till förändringar i din applikation och hotlandskapet.

Vad är Cross-Origin Resource Sharing (CORS)?

Cross-Origin Resource Sharing (CORS) är en mekanism som tillåter webbsidor från ett ursprung (domän) att komma åt resurser från ett annat ursprung. Som standard tillämpar webbläsare en Same-Origin Policy, som hindrar skript från att göra förfrågningar till ett annat ursprung än det som skriptet kommer ifrån. CORS ger ett sätt att selektivt lätta på denna begränsning, vilket möjliggör legitima korsursprungsförfrågningar samtidigt som det skyddar mot skadliga attacker.

Förstå Same-Origin Policy

Same-Origin Policy är en grundläggande säkerhetsmekanism som förhindrar ett skadligt skript från en webbplats från att komma åt känslig data på en annan webbplats. Ett ursprung definieras av schemat (protokoll), värden (domän) och porten. Två webbadresser har samma ursprung om och endast om de har samma schema, värd och port.

Till exempel:

• https://www.example.com/app1/index.html och https://www.example.com/app2/index.html har samma ursprung.
• https://www.example.com/index.html och http://www.example.com/index.html har olika ursprung (olika schema).
• https://www.example.com/index.html och https://sub.example.com/index.html har olika ursprung (olika värd).
• https://www.example.com:8080/index.html och https://www.example.com:80/index.html har olika ursprung (olika port).

Hur CORS fungerar

När en webbsida gör en korsursprungsbegäran skickar webbläsaren först en "förhandsbegäran" till servern. Förhandsbegäran använder HTTP OPTIONS-metoden och innehåller huvuden som indikerar HTTP-metoden och huvuden som den faktiska begäran kommer att använda. Servern svarar sedan med huvuden som indikerar om korsursprungsbegäran är tillåten.

Om servern tillåter begäran inkluderar den huvudet Access-Control-Allow-Origin i svaret. Detta huvud specificerar de ursprung som får komma åt resursen. Webbläsaren fortsätter sedan med den faktiska begäran. Om servern inte tillåter begäran inkluderar den inte huvudet Access-Control-Allow-Origin, och webbläsaren blockerar begäran.

CORS-huvuden: En detaljerad titt

CORS förlitar sig på HTTP-huvuden för att kommunicera mellan webbläsaren och servern. Här är de viktigaste CORS-huvuden:

• Access-Control-Allow-Origin: Anger de ursprung som får komma åt resursen. Detta huvud kan innehålla ett specifikt ursprung (t.ex. https://www.example.com), en jokertecken (*) eller null. Att använda * tillåter begäranden från vilket ursprung som helst, vilket generellt sett inte rekommenderas av säkerhetsskäl. Att använda `null` är endast lämpligt för "opak svar" som när resursen hämtas med protokollet `file://` eller en data-URI.
• Access-Control-Allow-Methods: Anger de HTTP-metoder som är tillåtna för korsursprungsbegäran (t.ex. GET, POST, PUT, DELETE).
• Access-Control-Allow-Headers: Anger de HTTP-huvuden som är tillåtna i korsursprungsbegäran. Detta är viktigt för att hantera anpassade huvuden.
• Access-Control-Allow-Credentials: Indikerar om webbläsaren ska inkludera autentiseringsuppgifter (t.ex. cookies, auktoriseringshuvuden) i korsursprungsbegäran. Detta huvud måste ställas in på true för att tillåta autentiseringsuppgifter.
• Access-Control-Expose-Headers: Anger vilka huvuden som kan exponeras för klienten. Som standard exponeras endast en begränsad uppsättning huvuden.
• Access-Control-Max-Age: Anger den maximala tid (i sekunder) som webbläsaren kan cachelagra förhandsbegäran.
• Origin: Detta är en begäranshuvud som skickas av webbläsaren för att indikera begäranens ursprung.
• Vary: Ett allmänt HTTP-huvud, men viktigt för CORS. När `Access-Control-Allow-Origin` genereras dynamiskt bör huvudet `Vary: Origin` inkluderas i svaret för att instruera cachningsmekanismer att svaret varierar beroende på begäranshuvudet `Origin`.

Praktiska CORS-exempel

Låt oss titta på några praktiska exempel på CORS-konfigurationer:

Exempel 1: Tillåta begäranden från ett specifikt ursprung

Denna konfiguration tillåter endast begäranden från https://www.example.com:

            Access-Control-Allow-Origin: https://www.example.com
            

              
                Copy
              
            
          

Exempel 2: Tillåta begäranden från valfritt ursprung (rekommenderas inte)

Denna konfiguration tillåter begäranden från valfritt ursprung. Använd med försiktighet eftersom det kan introducera säkerhetsrisker:

            Access-Control-Allow-Origin: *
            

              
                Copy
              
            
          

Exempel 3: Tillåta specifika metoder och huvuden

Denna konfiguration tillåter metoderna GET, POST och PUT, och huvudena Content-Type och Authorization:

            Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
            

              
                Copy
              
            
          

Exempel 4: Tillåta autentiseringsuppgifter

För att tillåta autentiseringsuppgifter (t.ex. cookies) måste du ställa in Access-Control-Allow-Credentials på true och ange ett specifikt ursprung (du kan inte använda * när du tillåter autentiseringsuppgifter):

            Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Credentials: true
            

              
                Copy
              
            
          

Du måste också ställa in credentials: 'include' i din JavaScript fetch/XMLHttpRequest-begäran.

            fetch('https://api.example.com/data', {
  credentials: 'include'
})
            

              
                Copy
              
            
          

CORS-förhandsbegäranden

För vissa typer av korsursprungsbegäranden (t.ex. begäranden med anpassade huvuden eller metoder andra än GET, HEAD eller POST med Content-Type av application/x-www-form-urlencoded, multipart/form-data eller text/plain) skickar webbläsaren en förhandsbegäran med metoden OPTIONS. Servern måste svara på förhandsbegäran med lämpliga CORS-huvuden för att indikera om den faktiska begäran är tillåten.

Här är ett exempel på en förhandsbegäran och ett svar:

Förhandsbegäran (OPTIONS):

            OPTIONS /data HTTP/1.1
Origin: https://www.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type, Authorization
            

              
                Copy
              
            
          

Förhandssvar (200 OK):

            HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400
            

              
                Copy
              
            
          

Huvudet Access-Control-Max-Age anger hur länge webbläsaren kan cachelagra förhandssvaret, vilket minskar antalet förhandsbegäranden.

CORS och JSONP

JSON with Padding (JSONP) är en äldre teknik för att kringgå Same-Origin Policy. JSONP har dock betydande säkerhetsrisker och bör undvikas till förmån för CORS. JSONP förlitar sig på att injicera <script>-taggar på sidan, vilket kan exekvera godtycklig kod. CORS ger ett säkrare och mer flexibelt sätt att hantera korsursprungsbegäranden.

Bästa metoder för CORS

• Undvik att använda *: Undvik att använda jokertecknet (*) i huvudet Access-Control-Allow-Origin, eftersom det tillåter begäranden från vilket ursprung som helst. Ange istället de specifika ursprung som får komma åt resursen.
• Var specifik med metoder och huvuden: Ange de exakta HTTP-metoder och huvuden som är tillåtna i huvudena Access-Control-Allow-Methods och Access-Control-Allow-Headers.
• Använd Access-Control-Allow-Credentials med försiktighet: Aktivera endast Access-Control-Allow-Credentials om du behöver tillåta autentiseringsuppgifter (t.ex. cookies) i korsursprungsbegäranden. Var medveten om säkerhetsimplikationerna av att tillåta autentiseringsuppgifter.
• Säkra dina förhandsbegäranden: Se till att din server hanterar förhandsbegäranden korrekt och returnerar rätt CORS-huvuden.
• Använd HTTPS: Använd alltid HTTPS för både ursprunget och de resurser du kommer åt korsursprung. Detta hjälper till att skydda mot man-in-the-middle-attacker.
• Vary: Origin: Om du dynamiskt genererar huvudet `Access-Control-Allow-Origin`, inkludera alltid huvudet `Vary: Origin` för att förhindra cachningsproblem.

CSP och CORS i praktiken: En kombinerad strategi

Även om CSP och CORS båda tar itu med säkerhetsproblem, fungerar de på olika lager och ger kompletterande skydd. CSP fokuserar på att förhindra att webbläsaren läser in skadligt innehåll, medan CORS fokuserar på att kontrollera vilka ursprung som kan komma åt resurser på din server.

Genom att kombinera CSP och CORS kan du skapa en mer robust säkerhetsposition för dina webbapplikationer. Du kan till exempel använda CSP för att begränsa de källor från vilka skript kan läsas in, och CORS för att kontrollera vilka ursprung som kan komma åt dina API-slutpunkter.

Exempel: Säkra ett API med CSP och CORS

Låt oss säga att du har ett API som finns på https://api.example.com som du vill ska vara tillgängligt endast från https://www.example.com. Du kan konfigurera din server att returnera följande huvuden:

API-responshuvuden (https://api.example.com):

            Access-Control-Allow-Origin: https://www.example.com
Content-Type: application/json
            

              
                Copy
              
            
          

Och du kan konfigurera din webbplats (https://www.example.com) att använda följande CSP-huvud:

Webbplatsens CSP-huvud (https://www.example.com):

            Content-Security-Policy: default-src 'self'; script-src 'self'; connect-src 'self' https://api.example.com;
            

              
                Copy
              
            
          

Denna CSP-policy tillåter webbplatsen att läsa in skript och ansluta till API:et, men hindrar den från att läsa in skript eller ansluta till andra domäner.

Slutsats

Content Security Policy (CSP) och Cross-Origin Resource Sharing (CORS) är viktiga verktyg för att härda säkerheten för dina frontend-applikationer. Genom att noggrant konfigurera CSP och CORS kan du avsevärt minska risken för XSS-attacker, datainjektionsattacker och andra säkerhetsproblem. Kom ihåg att börja med en restriktiv policy, testa noggrant och kontinuerligt övervaka och förfina din konfiguration för att anpassa dig till förändringar i din applikation och det föränderliga hotlandskapet. Genom att prioritera frontend-säkerhet kan du skydda dina användare och säkerställa integriteten hos dina webbapplikationer i dagens alltmer komplexa digitala värld.